General Packet Radio Service (GPRS) is commonly available in cellular telephone networks to transmit voice and other application data between a mobile station (MS) (e.g., a cellular telephone) and a base station. GPRS utilizes packet based communications. That is, application data transmitted between the MS and the base station is grouped into packets or protocol data units (PDUs). As used herein the term protocol data unit means data in a format specified by a protocol, which data includes a header containing protocol control information (e.g., address information for routing the protocol data unit) and possibly a data portion containing application data or another protocol data unit.
As illustrated in FIG. 1, an MS 102 may include one or more processes 105 (e.g., a voice call, a web browser, and a text messaging client) that send and receive application data to other devices attached to an external network (e.g., the Internet) via wireless communication 116 with a base station 104. As shown in FIG. 1, the MS 102 may typically include a multi-level GPRS protocol stack for converting PDUs created by the processes 105 (e.g., Internet Protocol (IP) packets) to PDUs suitable for wireless transmission over a GPRS network. The GPRS protocol stack in the MS 102 will usually include transport/network layers 106 (e.g., TCP/IP, UDP/IP, etc.), a logical link control (LLC) layer 108, a radio link control (RLC) layer 110 including at least one RLC engine 111 (i.e., RLC entity) for performing the functions of the RLC layer 110, and a media access control (MAC)/physical (PHY) layer 112. Each layer in the transmission protocol stack may receive a PDU from the layer above, perform various transformations on the received PDU (e.g., segmentation, adding additional headers, etc.), and transmit the resulting PDU(s) to the next layer. (For receiving data, each layer may receive one or more PDUs from the layer below, perform various transformations (e.g., reassembly of larger PDUs, removing headers, etc.), and provide the resulting PDU to the layer above.) For example, a process 105 may generate application data for transmission. The network layer 106 converts this data to a network layer PDU (e.g., an IP packet), the LLC layer 108 converts the network layer PDU to an LLC PDU, the RLC layer converts the LLC PDU to one or more RLC PDUs (i.e., RLC data blocks), and the MAC/PHY layer may add a MAC header to the RLC data blocks to generate RLC/MAC data blocks and transmit these blocks over the physical link (e.g., the wireless antenna 114). It is possible that some or all of the layers may be combined. For example, although the RLC layer and MAC layer are shown as separate layers, they may be combined to form an RLC/MAC layer.
Different categories of processes 105 may prioritize different attributes of network resources based on the nature of the application data requiring transmission. For example, voice conversations are highly sensitive to network delays, but can tolerate some lost information. On the other hand, digital computer data transfers to and from servers (e.g., downloading and interacting with world wide web pages) may be more tolerant of brief transmission delays, but may require that all packets are successfully delivered. These different priorities can be generally characterized as quality of service (QoS) attributes. For example, voice conversations may have QoS attributes reflecting a desire for prompt transmission, but not necessarily guaranteed delivery (e.g., packets that are unsuccessfully transmitted (i.e., dropped) may not be retransmitted or even acknowledged as dropped by the receiving entity). On the other hand, digital computer data transfers to and from servers may have QoS attributes requirements reflecting that the packets may be delayed if necessary, but that any dropped packets should be acknowledged and possibly retransmitted until successfully received. Additional characteristics of processes 105 may suggest other QoS attributes, and relative delay and error tolerances may vary between applications.
To specify each distinct set of QoS attributes required by processes 105, a session management (SM) protocol entity in the MS 102 may request the activation of a packet data protocol context (PDP context) from a peer SM protocol entity in the network controlling the base station 104 wherein each activated PDP Context corresponds to a specific process within the set of processes 105. For example, the MS 102 illustrated in FIG. 1 requires three different QoS settings (one for each process) and will request the activation of three distinct PDP contexts (one for each process). Each PDP context includes specified QoS attributes, as well as a PDP address (often an IP address) that identifies the MS 102. Following PDP context activation, when a specific process within the set of processes 105 executing on the MS 102 needs to transmit application data, the MS 102 will request the establishment of an uplink temporary block flow (TBF) that reflects the QoS attributes of the corresponding PDP context.
Multiple PDP contexts having the same QoS attributes may be grouped (i.e., aggregated) together into a single Packet Flow Context (PFC). The PFC shares the QoS attributes of the aggregated PDP contexts, and each PFC is uniquely identified by a packet flow identity (PFI).
When the MS 102 has application data ready to transmit for a given PFC (e.g., a specific process within the set of processes 105 on the MS 102 has generated one or more IP packets, which are converted to LLC PDUs by the LLC layer 108), it may request the establishment of an uplink temporary block flow (TBF) from the base station in order to transmit the application data. A TBF grants the MS a portion of the time division multiple access (TDMA) resources of the base station. For example, when assigning resources for a TBF the base station may grant an MS 102 access to the fourth TDMA timeslot on a specific frequency. Each TBF is identified by a unique temporary flow identifier (TFI) and supports an RLC entity 111 operating in a mode most appropriate for supporting the QoS attributes of the PFC supported by that TBF. (For example, an RLC entity 111 may operate in an RLC Acknowledged mode wherein dropped RLC data blocks are retransmitted, an RLC Unacknowledged mode wherein dropped RLC data blocks are not retransmitted, or an RLC Non-persistent mode, wherein dropped RLC data blocks may be retransmitted within a certain time interval, after which the dropped RLC data block may be discarded.) Once it has acquired an uplink TBF, the MS may then use the allocated radio resources to transmit the waiting LLC PDU(s) for the corresponding PFC. The LLC layer 108 sends the waiting LLC PDU(s) to the RLC layer 110, at which the appropriate RLC entity 111 divides each LLC PDU into a corresponding set of one or more RLC data blocks. As shown in FIG. 2, in addition to a data payload section 203, each RLC data block includes a TFI field 201 indicating the TFI of the allocated TBF and a block sequence number (BSN) field 202 that sequentially numbers the RLC data blocks being transmitted in a TBF. The TFI is used to uniquely identify the TBF and therefore the corresponding PFC for which application data needs to be transmitted since in legacy systems there is a one to one relationship between a TFI and a PFC. The BSN may be used by the receiving entity to detect any dropped (lost) RLC data blocks. The RLC data blocks are then sent to the MAC/PHY layer(s), where each may be given an additional MAC header with radio access information (e.g., a countdown timer indicating when the MS will no longer require the allocated resources). The RLC/MAC data blocks are then transmitted wirelessly to the base station. When the MS has finished transmitting all of the available application data from the processes 105, it releases the current TBF resources, either immediately or after an extended waiting period. The MS 102 may acquire a new TBF when the MS 102 is ready to transmit one or more additional LLC PDU(s).
Using the above described method for transmitting application data, it may occur that application data corresponding to a PFC with a relatively high transmission priority (e.g., an LLC PDU associated with a PDP context/PFC data having QoS attributes that indicate a low tolerance for delay) becomes ready for transmission while application data corresponding to a PFC with a relatively low transmission priority (e.g., an LLC PDU associated with a PDP context/PFC having QoS attributes that indicate a tolerance for moderate delays) is currently being transmitted. Furthermore, even though they have different transmission priorities, it may occur that both of these PFCs can be supported using an RLC entity operating using the same mode. According to legacy operation, the occurrence of this scenario will be handled by first completing the transmission of the LLC PDU having a relatively low transmission priority using the existing uplink TBF, releasing the uplink TBF and then establishing a new uplink TBF to be used for transmission of the LLC PDU having a relatively high transmission priority. This is problematic as it may result in an unacceptable delay being imposed upon the transmission of the application data associated with the higher priority PFC. It is further assumed that this legacy operation can be enhanced so as to avoid the step of releasing and establishing a new uplink TBF whenever this scenario occurs such that the problematic delay imposed upon the LLC PDU having a relatively high transmission priority will be limited to that of first completing the transmission of LLC PDU having a relatively low transmission priority. Assuming this enhancement to legacy operation is applied and referring now to FIG. 3, FIG. 3 illustrates that a message flow diagram for this case. At a first time, a process associated with a lower priority PFC creates an LLC PDU 301 containing the data “n-o-n-e-s-s-e-n-t-i-a-l”. The transmitting RLC entity divides the LLC PDU into several RLC data blocks and begins to transmit these RLC data blocks 302 to the receiving RLC entity (e.g., a base station). At a later time, but before all of the RLC blocks from the first LLC PDU 301 have been transmitted, a second process associated with a higher priority PFC creates an LLC PDU 303 containing the data “u-r-g-e-n-t”. However, the RLC entity continues to transmit the RLC data blocks from the low priority LLC PDU 301 until the entire LLC PDU has been transmitted. At this point, the receiving RLC entity reassembles the low priority LLC PDU as LLC PDU 305 and relays it to the appropriate LLC entity such that the application data contained therein can be delivered to the peer process. After the low priority LLC PDU 301 is completely transmitted, the RLC entity may then enable the transmission of the RLC data blocks corresponding to the high priority LLC PDU 303 and begin transmitting those RLC data blocks 306 by continuing to use the same RLC entity on the already established TBF. Finally, when all of the RLC data blocks 306 have been received at the receiving RLC entity, the receiving RLC entity reassembles the RLC data blocks of the high priority LLC PDU as LLC PDU 307 and relays it to the appropriate LLC entity such that the application data contained therein can be delivered to the peer process. As can be seen in FIG. 3, the relatively higher priority application data 303 associated with high priority LLC PDU 303 is undesirably delayed by the ongoing transmission of all of the lower priority application data 301 associated with low priority LLC PDU 301.